Fehlerhaften .NET-Code schneller zur Strecke bringen

Ein Aspekt von Teamarbeit ist, dass einzelne Entwickler (oder Gruppen) lokal Funktionen entwickeln und herstellen können, bevor sie diese mit dem zentralen Repository zusammenführen, in dem alle Änderungen enthalten sind. Entwickler testen und debuggen lokal mit der aktuellsten Version und hoffen dann, dass auch alles mit der Arbeit der anderen Entwickler zusammen funktioniert. Man kann das manuell testen, ein besserer Ansatz ist aber, das Verfahren zu automatisieren, um sofort ein Feedback zu erhalten. Eine hervorragende Lösung dafür ist die kontinuierliche Integration, mit welcher der Erstellungsprozess automatisiert werden kann und man sofort ein Feedback über .NET-Coding-Fehler erhält.

Kontinuierliche Integration

Es gibt verschiedene Philosophien für die Verbesserung der Produktivität und Effizienz von Anwendungsentwicklungsteams. Einer dieser Ansätze heißt kontinuierliche Integration. Eine grundlegende Voraussetzung für eine kontinuierliche Integration ist sofortiges Feedback. Die einfachste Form von kontinuierlicher Integration ist ein Entwickler, der allein arbeitet, weil so alle Änderungen sofort zu sehen sind. So bemerkt der Entwickler Probleme, sobald sie auftauchen. Der gleiche Ansatz wird bei einer Teamumgebung verwendet, so dass Probleme rechtzeitig erkannt werden.

Die beste Eigenschaft von kontinuierlicher Integration liegt darin, die Entwickler weniger Zeit brauchen um die Fehler zu finden, wenn andere Entwickler ihre Arbeit prüfen und Probleme auftauchen. Diese Fehler sind normalerweise schwer zu finden, denn das Problem resultiert aus der Integration neuen Codes. Die Fehler können Wochen oder Monate, bevor sie das erste Mal auftauchen, eingebaut worden sein. Die Zeit, die man zur Fehlersuche braucht, könnte man besser für andere Projektaufgaben verwenden. Es kommt daher darauf an, die Probleme möglichst schnell zu finden.

Bei kontinuierlicher Integration werden die meisten Bugs schon bei ihrer Einführung gefunden und der Schuldige (das heißt der Code des Entwicklers) ist deutlicher zu erkennen, da der Code vor dem Übernehmen geprüft wurde. Je weniger Zeit also dafür verwendet wird, den Fehler zu finden, umso mehr Zeit haben Entwickler, ihre eigenen Probleme zu lösen. Das Ergebnis ist ganz klar ein Produktivitätsgewinn. Allerdings setzt dies das häufige Erzeugen von Builds voraus, um den Entwicklern ein brauchbares Feedback zu liefern.